Subject: DLSw: IETF Decision Status

From: [email-masked]
Date: Tue, 17 May 94 05:31:50 PDT

DLSw RIGgers!

ACTION ITEM:
Post your comments regarding DLSw and its relationship to 
IETF by Friday May 20, if you have not done so already.
(The full text of the Invitation to Discussion is found at 
the end of this message, in case you have mislaid your copy.  
Read before responding.)

TIMEFRAME:
I propose that we finalize our decision regarding whether 
(and if so, how) to IETF next week.  To do this, I request 
that all interested companies add their opinion by Friday, 
May 20.  I will do another summary over the weekend and we 
will discuss all the input next week.

STATUS:
Most opinion seems to be falling about equally into two of 
the four options that I proposed:  Either "Post the AIW DLSw 
closed pages (CP) as an informational RFC" or "Pursue IETF 
standard in parallel with AIW CP."

1.	Ed Stern, Proteon              #2 
2.	Wayne Clark, Cisco             #4
3.	Scott Barvick, Wellfleet       #2
4.	John Pickens, consultant       #2
5.	Alan Bartky, Sync Research     #4 
6.	Shannon Nix, Metaplex          #4
7.	David Bryant, 3Com             #2
8.	Peter Gayek, IBM               #2
9.	Elazar (Azi) Ronen, RADlinx    #2
10.	Kevin Loo, Ascom Timeplex      #2
11.	David Matusow, Hypercom        #4 
12.	Mike Otto, Netlink             #4
13.	Bill Kwan, Crosscomm           new option #5:
                                    IETF standard
                                    instead of AIW CP
                                    (or option #4)

(Note:  Wayne's message indicated he wanted to pursue an IETF 
standard, but did not specify whether he preferred serial or 
parallel processing -- from our prior discussions, I believe 
he prefers #4 - parallel.)

As a reminder, the four possible relationships I noted that 
the DLSw RIG may choose to have with the IETF:
#1  No relationship at all.
#2  Post AIW DLSw closed pages as an informational RFC.  
#3  Pursue DLSw IETF standard after AIW DLSw closed 
         pages.
#4  Pursue DLSw IETF standard in parallel with pursuing 
        AIW closed pages.

I have enclosed the full text of all the input received so 
far.  I have been impressed and delighted by these well-
considered thoughful responses.  Please review the different 
opinions and reasons and be as open as you can with regard to 
allowing the input to influence your thinking.  Consider some 
ways to reach consensus with these two different options.  

Keep in mind:  One basic assumption of the consensus process 
is that, in addition to being individuals in a group, we are 
also each part of the group.  We are not only participating 
to serve our employer or our ego directly.   We also serve 
our common goal - our customers and the industry.  Thus -- 
indirectly but more powerfully together -- we improve our 
bottom line.  Our customers are not served by bickering, 
delays, and power plays.  They are served by the best minds 
in the industry working together.  

Regards,

Louise Herndon Wells

From: [email-masked] (Edward L. Stern)
Proteon

Louise, Riggers,

I am quite pained, but not surprised, at the incredible 
amount of confusion that we have caused, both in the press 
and with our customers, by our test probe into the IETF.  We 
knew this was a risk when we decided to take our current 
course of action. Now that we know the extent of this 
confusion, I strongly believe that any advantages that would 
be gained by forming an IETF working would be more than 
offset by the disadvantages.

It is extremely important that we head down a path to dispel 
this confusion, which seems to be taking 2 forms.  The first, 
which is the most important, is "how many standards are we 
producing, and which one is the official one?".  We have to 
give a clear answer, and give it NOW.  The only way to do 
this, and have a standard in a reasonable length of time 
(i.e. this year) is to drop any attempt to form an IETF 
working group.  Otherwise, we WILL be producing 2 standards, 
and even though we may know (or believe) that the AIW and 
IETF standards will be the same, we will never get that 
message out to the press and our customers.  It is too hard 
to explain, the press WANTS conflict and confusion because it 
makes good headlines, and we will be spending a majority of 
the next year at our meetings wasting our time with these 
kinds of issues rather than technical ones.  

The second form of confusion is that we are a "split camp" of 
some sort.  Depending on who I am talking to (these are 
customers I am talking to) the split is either 1) pro IBM vs. 
pro cisco, 2) pro DLSw vs. anti DLSw, 3) pro IETF vs. pro 
RIG.  And there are a score of variations on and theories 
about these splits.

Now maybe there are some issues where we are divided, but I 
believe that we are all in agreement (i.e have CONSENSUS) on 
one issue, which is that we all want ONE DLSw STANDARD.  We 
have to get that message out, loud and clear.  That message, 
which is far and away the most important one, is being lost.

I know we all wish we could just go about the business of 
producing a technical document and not have to worry about 
the rest of this garbage.  If we make the right decision now 
we can have that wish.

Therefore I would vote for number Louise's #2, no IETF 
working group, but publish the RIG standard as an 
informational RFC.

Ed Stern
Proteon, Inc.

-----

From: Wayne Clark <[email-masked]>
Cisco

Louise, Ed, et.al. -

    When we started the whole DLSw process over a year ago, 
the     decision was made to meet at the AIW to work on the 
technical     details of making it a standard.  We also 
stated at that time that     the eventual product of that 
work would be a submission to the IETF     so that our 
efforts could result in a standard.  What I now hear is     
that some people want to retract that goal. 

This whole issue surrounding "2 standards" is a smokescreen.  
I sense this feeling that, by being a part of the IETF, the 
sanctity  of our work at the AIW is going to somehow be 
compromised.  Both  organizations operate on the consensus 
model and there is no way  that stray requests for 
alterations can come into the process at  the IETF and change 
the spec without consensus.  The people  interested in 
working on DLSw at the IETF is a subset of vendors  working 
on it at the AIW.

    With that said, I would like to make the following 
points:

	(1) An informational RFC is not a standard.  Anyone off 
the street can write something down and use the IETF 
respository to hold their thoughts.  While companies can 
claim anything they want (and we've gots lots of good 
examples of this lately), a vendor cannot claim conformance 
to an informational RFC.  I suggest people check out Section 
2.4.3 of RFC 1602 (The Internet Standards Process -- Revision 
2).

	(2) There is nothing that can replace the value of 
having an Internet Standard.  Internet Standards are 
recognized by the industry.  No offense, Lee, but the AIW is 
not completely recognized yet as a stardards body.

	(3) The industry's expectations have been raised with 
respect DLSw and the industry is expecting an Internet 
Standard. Anything less than this would be viewed as a 
failure of the DLSw working group.

    By the way, many people are at Interop this week so you 
might not get many responses until Interop is over.

Wayne

-----

From: [email-masked] (Scott Barvick)
Wellfleet

In response to the question "To IETF or not to IETF...", 
Wellfleet's view is based on two important considerations; 
the need for a standard and the AIW's ability to effectively 
produce thestandard.

1) We need a reference point that everyone can refer to which 
indicates the operation and interoperability expected from a 
standard. This reference point currently is RFC 1434.  It has 
been very effective in defining what our product is, what it 
does, and who it will work with. Customers have not been 
concerned about its status as an  Informational RFC.  It is 
referred to by the AIW and customers as  "RFC 1434", not "for 
information only RFC 1434".  Unless someone actively attempts 
to FUD the issue with the fact that it is not  some sort of 
IETF-processed document, customers know exactly what the 
scope is, who is working on it, and where it is going.

Having an RFC designation is useful because the industry 
likes to have an RFC # to reference a particular piece of 
functionality, but an administrative distinction between 
informational and "real" is not critical when customers 
understand how the RFC was developed. 

2) Our representatives from the SNA world are committed to 
the AIW and have not generally attended the IETF.  It is 
basically a time constraint.  It appears that the IETF will 
not be a forum that just accepts the work done by the people 
who really know the issues and are actually building the 
products.  Louise's mail indicates a few  differences in 
operation between the IETF and the AIW which will  
undoubtedly slow down the process.  Serially or in parallel, 
even work unhindered by IETF rules (which we did not develop 
as in the AIW), will delay delivery of a "standard" defining 
new DLSw operation.  I am confident that many of the IETF 
contributors who want to contribute to the DLSw standard will 
not have the time to attend AIW meetings in order to become 
familiar with the background and current issues.

These two important arguments lead us to support the 
informational RFC as our relationship with the IETF.  We will 
get a standard  which defines the interoperability of our 
products for our customers without using our already limited 
time on duplicated effort.

Scott Barvick
[email-masked]

-----

From: [email-masked] (John R. Pickens)
Consultant

Louise, good summarization of the options.  Might I offer an 
opinion?

In the interest of minimizing time to market it would be a 
pity to get tied up in the politics of standards turf 
battles.  If the IETF procedures are incapable of accepting 
the work of an external multvendor consortium as an IETF 
standard, then so be it.   

The alternatives then would seem clear.  

My suggestion would be to finish the multivendor AIW standard 
for DLS and publish it as an informational RFC (which is a 
great vehicle for text distribution).  Meanwhile if someone 
feels a need to create an IETF working group, go for it.  
This is a society in which freedom of choice is a well 
defended right.  Should such a working group be formed, 
liason functions can be formed between that group and the 
AIW, if anyone has the energy or gumption for it.

There are many examples of multiple standards bodies working 
on related  and sometimes overlapping work, however unsavory.  
I myself have been part  of a standards effort where the 
primary effort was split between IEEE 802 and ITU (i.e. 802 
prime for some work, ITU prime for other), and in which 
liason efforts were also needed with ANSI.  No big deal.  

Probably too much ado is being made over the rigid procedures 
ofIETF/AIW.  And probably too much energy is being consumed 
over a unattainable objective, the creation of a common 
document that is blessed by both AIW and IETF as a standard. 

JP

-----

From: "Alan K. Bartky, Manager of Technology" 
<[email-masked]>
Sync Research

Our opinion, at Sync Research, is to:

4)  Pursue DLSw IETF standard in parallel with pursuing 
AIW closed pages.

Reasons for this are:

1) An IETF standard will carry more weight than a
blessed standard from the AIW.  There are 1600+ RFCs
covering multiple topics.  Only the "standard" RFCs
can be used to claim complience to.

2) Pursuing in parallel will decrease the overall time in
getting an IETF standard out.

3) I don't think the coordination between the groups will
be difficult.

4) There is a lot of press (ref Computerworld, and LAN Times
4/25/94) about the feuding between companies on RFC 1434 
"compliance" versus waiting for the next version of
the standard for interoperability.  I believe making
this a standard recognized by the IETF can stop
the feuding and have the chance of having an interoperable
standard.

5) There has been joint work and development outside
the auspices of the AIW between AIW member companies
without the sharing between all members.  This sharing
of info, "RFC 1434 interoperability testing" by Interlab,
and other activities is confusing the industry and
gives the feeling of not working together.  Working
towards an IETF standard would force the process to be more
open.

6) Much of the opinions expressed so far seem to be breaking
into the "haves" versus the "have-nots".  Those with existing
implementations are lining up behind not making DLSw an
IETF standard.  Wayne is right about the smokescreen.  The
reasons for killing the standards effort are political,
not technical.

7) Going for an IETF standard will open up the protocol 
mainly to an Auditing process and it should not change the 
technical content, unless things like an error in the 
protocol is found, the protocol is not well enough documented 
etc.  Using the IETF process will force us to have a standard 
that is completely  documented so that anyone can implement 
the protocol based on the document.  The IETF requires two 
INDEPENDENT implementations based on the document before it 
is accepted as an IETF standard.

Those vendors now "supporting RFC1434" are really saying that 
they can interoperate with the IBM 6611, not that they have 
implemented 100% based on the RFC.  We all know that there 
are changes in the 6611 which have not been documented in the 
RFC.

8) This group has already announced to the press that we are 
working towards making DLSw an IETF standard based on the 
consensus reached at the last AIW.  As you know it made all 
the major trade magazines and newspapers.  Changing our 
position now would send the wrong message to the industry and 
would also be "thumbing our noses" to the IETF.

These are my thoughts so far.  I may comment further as we 
start getting more responses back to Louise's poll.

Regards,

Alan K. Bartky
Sync Research Inc.

-----

From: "Shannon Nix" <[email-masked]>
Metaplex

 Hi,

 Metaplex would advocate pursueing the IETF standard in 
parallel with the AIW work.  Reasons follow:

There are only two of the four options which result in 
something we can call a standard.  The AIW is not a standards 
body!  Therefore, the outputs of options one and two are 
better characterized as an implementation agreement among AIW 
members.

We believe there is significant value in establishing a 
proper standard.

1.  The rigor applied by standards bodies is established and 
recognized as a process that works.  It enhances the output, 
rather than detracting from it.

 2.  Industry acceptance of IETF standards.

 3.  Inertia of the perception that a standard is to be our 
output. Can we really retract this without damaging how we 
are perceived?

 4.  It feels more "open".

Having said that, we believe that parallel pursuit of 
astandard is logistically superior to pursueing it serially.

1.  We have a standard sooner

2.  We don't have synchronization problems with milestones 
from two bodies.

Now that I have stated our position, I would like to rebut 
some of the FUD that is being heaped on the IETF process.

1.  The IETF has NO problems with the AIW being the venue for 
our primary working sessions.  The key thing is that any work 
accomplished at these sessions must be ratified on the net.  
This is so that those unable to attend the working sessions 
are still a part of the decision process.  Correct me if I'm 
wrong, but this is good!

2.  Certainly the IETF would have a higher level of comfort 
if we convened at some of their regular meetings.  This 
could, however, serve a liason function.  In the spirit of 
the above comment, nothing can be "decided" at these 
meetings!

3.  As Wayne pointed out, if we, as a body, are not able to 
defend our work and decisions against these hordes of 
academics that are alledgedly to come out of the woodwork 
when we open the process up, then we stand to benifit from 
having opened it up.  Sound technical decisions WILL stand up 
and be ratified.  Untenable ones need the help!

4.  This intellectual property stuff...are we really any 
better off under the AIW agreement than operating within the 
IETF framework?  How many of us, as vendors, are going to 
completely sequester ourselves from the public domain?

IN SUMMARY:

 1.  The IETF process works.  Look at the results.
 2.  AIW IS the right group to do the work.
 3.  AIW is NOT a standards body.
 4.  Standards are good. Customers like them.

SO.. let's use the IETF process to take the good work being 
done by the AIW members to the industry as a standard!!

Regards Shannon

-----

From: David Bryant  <David_Bryant/HQ/[email-masked]>
3Com Corporation

3Com Corp is in favor of option 2:  Develop the DLSw in the 
AIW and deliver it to the IETF as an informational RFC. 

The reasons are as follows:

1.  The industry perception of IETF "RFCs" (both 
informational and standard specifications) is deemed a 
positive stamp of approval.  Therefore, there is value to 
IETF RFC status and option 1 (AIW only) is not desirable.

2. Option 3 (IETF after AIW closed pages) is not viable as 
this may result in multiple DLSw  specifications which are 
not the same at worst.  And at best it delays the 
standardization process due to serialization.

3. Option 2 is quicker than option 4.   This is clearly true 
for several reasons.  The IETF  process has not yet begun and 
it has a number of stages just as the AIW does.   The IETF 
requires two interoperable implementations based upon the 
specification, the AIW does not.  

4.  From our perspective the vast majority of the industry 
does not make a distinction  between informational RFCs and 
IETF standard RFCs.   Thus an informational RFC seems to 
accomplish the goal of industry acceptance associated with 
IETF RFCs.   

5. What is truly critical is that the DLSw specification (AIW 
or IETF standard), be written to facilitate consistent  
interoperable implementations amongst multiple vendors which   
provide a valuable network solution to our customers.  This 
can be accomplished in either the AIW or the IETF assuming we 
do not grant "standard" or "CP" status in a frivolous manner.  
So in this sense, the IETF standard is not required.

6.  Interactive participation from the IETF will require 
additional effort that does not seem  business case 
justified.  If not simply attending more meetings, clearly 
following more activity on the internet.

7. Pursuit of an IETF standard will only prolong the 
standardization of DLSw (as noted in bullet 3), which will 
further thwart AIW member attempts to develop a marketable 
SNA/NetBios TCP/IP encapsulation technique thus maintaining 
the marketplace status quo.  

David Bryant

-----

From: [email-masked]
Peter Gayek, IBM

I attended the IETF BOF in Seattle and am convinced that the 
benefit of having an IETF standard (versus an informational 
RFC) is far out- weighed by the additional delay and effort 
of working it through the IETF.  My opinion, and IBM's 
position, is that the RIG should post a completed AIW 
standard as an informational RFC (option 2).

My reasons are as follows, in rough priority order (1 & 2 are 
different facets of the same issue and are about equal):

1) Calendar time to having an implementable standard

Options 3 and 4 both delay having a customer-accepted 
implementable standard by at least six months.  For option 3, 
this is because once we say we will take it to the IETF, we 
are implicitly saying that what the RIG produces is not final 
enough to be trusted as a standard. So many customers will 
not feel comfortable until IETF Proposed Standard status is 
granted.  In the absolute best case, when non-RIG IETF 
commenters say absolutely nothing (an absurd assumption), we 
will have moved "implementable standard" status from 7/94 
(the earliest I think we can reach AP in the RIG), to 3/95 or 
4/95.  This is an 8-9 month slip just to get to IETF 
"proposed standard" status (not to mention the 2 steps 
following it, which require an additional 10 months for full 
standard status).

For option 4, once again, adoption implies that the IETF is 
what counts, so we are gated by what happens there.  The 
earliest I can possibly conceive of this option working is 
that "proposed standard" status would be granted after a 
review period following the December IETF meeting in San 
Francisco.  With the holidays, this means 1/95 or roughly a 6 
month slip.  Again, this assumes little new discussion. In 
fact, I would expect the real dates to be a number of months 
further into 1995.

These slips mean delayed customer acceptance of DLSw 
solutions, a longer period of confusion in the marketplace, 
and that instead of being busy full-time implementing 
products for our companies, we engineers will for many months 
more be attending meetings and doing protocol architecture.

2) Effort required by all of us to get to a standard

The ground rules for IETF involvement are completely open 
mailing lists, equal status of AIW and IETF meetings, and 
decisions reached by e-mail.  In addition, the area director 
has a fair amount of power to influence the scope of 
discussion and progress of the standard. With these ground 
rules and based on the technical interchange which took place 
at Seattle, I am convinced of the following:

     - Companies with more than a casual interest in DLSw 
will need to have representatives at both sets of meetings.  
At a minimum this means the June AIW, July IETF, October AIW, 
December IETF, February 95 AIW, and March 95 IETF.  Option 2 
means only two more AIW meetings and that's it for the 
initial release of the standard.

     - There will be at least a few non-RIG participants from 
the IETF, and while very capable may lack the general SNA and 
connection- oriented background typical of RIG members.  
Example from Seattle: objection was raised to frame-based 
pacing because "what if a client requested one byte at a time 
from a server?".

     - These participants, however few, will require energy 
from the rest of us to give DLSw/SNA background, and rehash 
old issues that were resolved in the RIG months ago.  Example 
from Seattle:  we should not have an independent circuit-
level pacing mechanism but have one circuit per TCP 
connection and let the TCP flow control mechanism be the only 
one.

     - We will be required to address with some effort the 
question of interoperation with RFC 1001/1002 (providing a 
NetBIOS API within an IP host).  We discussed this here on 
this mailing list before the BOF and I expected we could blow 
it off in two minutes as an end station solution within an IP 
host that has little relation to the problem DLSw is solving.  
To my surprise, more than one IETF leader took the question 
of interoperation as a possible requirement to be seriously 
considered.  (This statement is based partly on hall 
discussions outside the BOF).  Some IETF participants have a 
business interest in RFC 1001/1002 solutions, solutions which 
become less valuable if DLSw increases the number of native 
NetBIOS end stations attached to IP networks.  I believe that 
any requirement for DLSw to interoperate would be an absolute 
disaster and kill any hope for a near-term DLSw IETF 
standard.

The lack of participation on the RIG mailing lists since our 
February meeting leads me to believe that most of us are 
swamped and barely able to contribute to the RIG discussions.  
Even simple choices seem to take weeks to make. I know that 
some feel new participants could help, but my conclusion from 
Seattle is that going with the IETF will introduce more new 
and old issues than it will drive down the list we're 
currently struggling with.  While some positive contributions 
would certainly emerge from the IETF, I do not feel they 
would be worth the price we will have to pay in time and 
additional effort.

3) Customer / marketplace confusion

Either path which involves two standards bodies will continue 
the current confusion about what track we are on, what 
standard is the "real" one, and what timing a customer should 
expect.  It's very difficult to get across to the press and 
customers the nuances of how we expect the groups to work 
together and the different stages of completion of the 
standard(s).  I think option 2 would tremendously clarify the 
issue both for now and for the foreseeable future:  one 
working group and one specification.

4) Procedural / legal concerns about working with the IETF 
IBM legal's review of RFC 1602 (IETF standards process) has 
raised a number of concerns about its intellectual property 
provisions.  Louise referred to one but there are a few other 
issues.  We on this mailing list are engineers and are 
generally not worried about this stuff, but these issues have 
influenced the position IBM is taking and may be of concern 
to management and legal staff at other companies.

Now, I would like to respond to several arguments in favor of 
an IETF working group with which I do not agree.

A) The people will be the same as the RIG, so the risk of 
extraneous issues or rehashed discussion is very low.
 I agree that the great majority of participants will be the 
same. However, there will be at least a few (at least the 
area director, who I think will do his job diligently), who 
will want to understand the whole design and who will raise 
new and possibly fundamental objections to how DLSw operates.  
Only one or two persons without a direct business interest in 
the effort will have the ability to significantly delay the 
effort, and this concerns me.

B) IETF standard status is so valuable that it is worth any 
extra time or effort that may be required.

 In my mind the choice is between an informational and a 
standards-track RFC.  Many customers don't fully appreciate 
the difference.

   For those that do, let's assume for the moment we go with 
option 2.Then, if they want to route SNA and NetBIOS over IP, 
they will have a choice between:

     - a single vendor's proprietary solution

     - an informational RFC that represents the joint effort 
of every major SNA internetworking vendor

   Will customers reject the latter because it isn't a 
standards track RFC? I don't think so.  Customers accept and 
will continue to accept a variety of specifications - what 
counts is vendor agreement and interoperability.

I do not agree that the industry will think we have failed if 
we do not produce an IETF standard;  the industry wants us to 
work together and produce an interoperable specification.  It 
is continued press and customer confusion about IETF v. AIW 
that will produce a perception of failure.

C) Having IETF participants bring new perspectives and ideas 
is very desirable.

   Ok, it is to a point.  There may be some great ideas, or 
technical problems uncovered.  But, as we all know, adding 
more workers late in a project does not speed it to 
conclusion.  Even in the IETF, most things that reach 
standard status have a small dedicated group of people 
driving the process. The current RIG membership has a strong 
skill base;  I don't believe we're missing any critical 
skills in TCP/IP or any other area.   So while I'm sure the 
IETF process would add some value, I think we're at the point 
where it is more important to wrap things up than it is to 
invite new perspectives.

In short, while I understand the arguments for IETF standard 
status, I think it's time to concentrate our energies on 
closing out the current technical work in the AIW.  Even 
after this is done, the additional cost in time, effort, and 
confusion of seeking IETF standards status outweighs the 
benefit.

Peter Gayek
IBM Corp.

-----

From: [email-masked] (Elazar (Azi) Ronen)
RADlinx

RADLINX's vote is for option 2 "Post AIW DLSw closed pages as 
an informational RFC", for the following reasons:

1. We need one "Industry Standard" - and we need it fast

We need an "Industry Standard", that allows interoperability 
among vendors. The AIW process is faster, already started and 
is in a good postion to have a final document. The AIW is 
also acceptable by all players in the industry, therefore 
fulfilling this major requirement.

We are late so far, and adding more 'overhead', starting a 
new process, with new partners and different procedures will 
not help.

2. Risk of having two standards

Working with both AIW and IETF has the risk of having two 
standards, with a significant interval of time between the 
two. This will prevent vendors from implementing DLSw, due to 
the uncertainty about which is the standard (mainly due to 
the reason that the AIW will be the first). Today's status 
(of having the current 6611/RFC1434 DLSw and the 'future 
standard')is confusing enough - we do not need more!

3. Informational RFC is good enough

The term RFCxxx is good enough for our customers. They know 
that this means a well defined document, publicly available. 
The precise status is not important.

Azi Ronen, RADLINX
-------------------------------------------------------------
--
Elazar (Azi) Ronen                  Phone: +972 3-6475188
RADLINX Ltd.                        FAX  : +972 3-6475057
Tel-Aviv, Israel                    Email: 
[email-masked]

-----

From: "[email-masked]" <[email-masked]>
Kevin Loo, Ascom Timeplex

Regarding the "To IETF or not to IETF..." issue, Ascom 
Timeplex is in favor of option 2 (Post AIW DLSw closed pages 
as an informational RFC).

Our reasons for this decision have already been listed by 
other responses to this issue.  Our primary concern is that 
our customer's do not give added weight to an IETF "RFC 
Standard" designation so it is not worth the added delay to 
the standards process (perhaps three to six months).

Kevin Loo
ascom Timeplex

-----

From: [email-masked] (David Matusow)
David Matusow, Hypercom

>  1)  No relationship at all.
>  2)  Post AIW DLSw closed pages as an informational RFC.
>  3)  Pursue DLSw IETF standard after AIW DLSw closed 
>          pages.
>  4)  Pursue DLSw IETF standard in parallel with pursuing 
>          AIW closed pages.

We feel that the timing is important, but if the changes from 
1437 to the current state of DLSw is an indication, running 
serially will not get us where our customers want; that is, a 
interoperable methodology.  Our customers vary between IETF 
stamps being a checkmark to a requirement.  In my dealings 
recently, standards are becoming a clearer requirement, 
though.  With this in mind, we feel that:

1. DLSw must go through the IETF

   Without this "certification", our work will not be 
recognized.

2. running serially will NOT get us where we need to be 

   Our customers will be spooked by running in serial to the 
AIW.  This is because they either strongly desire a standard 
or demand one.  Running  serially will result in a lapse 
between AIW agreement and the IETF  "blessed" standard.  This 
timegap results in too long of a delay.

3. we may get more insight from the IETF members

   We are all smart, but there may be some insight from the 
IETF that we are not looking at.  This may be a result of a 
closed environment and none of us seeing some beautiful (or 
ugly) result of a decision.  (I don't put much credence in 
this, as none of us are truely or even symbolically closed, 
but you never know.)

As a result, Hypercom would vote for concurrent development.  
We don't feel that this should slow us up much, as the active 
participants will largely be those that are in AIW.  The 
intellectual property rights issue is not seen strongly by 
us.  We're here to submit input and make the solution better, 
not get highly involved in lawsuits in intellectual property.

I hope that this helps...or at least clarifies our viewpoint.

David Matusow
Hypercom Network Systems  

-----

From: [email-masked] (Mike Otto)
Netlink

Netlink's opinion regarding DLSw is to produce an IETF 
standard DLSw document in conjunction with producing the AIW 
closed pages (option #4).

Reasons for our choice:

At present, the IETF is highly visible and has a very 
successful track record for producing industry recognized 
standards. This carries a great deal of weight in the 
decision making process of our customers.  What confidence 
level will our customers have that a DLSw implementation from 
the AIW standard will inter-operate with one from the IETF 
standard?  Working in parallel will help to ensure that we 
produce a single standard DLSw specification. A synchronous 
approach (option #3) runs the risk of having two separate 
DLSw standards being produced, which will cause much 
confusion with our customers.

The DLSw group has already announced to the press that we are 
working towards producing an IETF DLSw document. A change in 
plans could send the wrong message to the user community that 
we have been unsuccessful in our efforts to produce an 
industry standard DLSw document. Working in parallel with the 
IETF to produce a single open DLSw standard will help add 
credibility to the AIW's efforts towards becoming an industry 
recognized standards body.

At present, the IETF members showing interest in producing a 
DLSw standard are largely a subset of the AIW DLSw group. 
And, since both groups work through a general consensus to 
make decisions, the process of working in parallel with the 
IETF should not prove to be difficult and time consuming.

Rgds,

Mike Otto
Netlink Inc.

*************************************************************
*  Mike H. Otto            Telephone: (919) 878 8612        *
*  Netlink, Inc.          Fax:       (919) 872 2132        *
*  3214 Spring Forest Road    Internet:  [email-masked]   *
*  Raleigh,  NC  27604                               *
*************************************************************
*

-----

From: Bill Kwan, Crosscomm
<@ibmstandards.cary.ibm.com:crossc!kwan
[email-masked]>

Dear DLSw Riggers,

I think it would be a mistake to back out pursuing a full 
IETF standard at this time. It will send a confusing and 
wrong message to the industry and our customers. Everybody is 
expecting this group to create a fully interoperable IETF 
standard. To do a reversal now will do serious damage to the 
group's credibility.

I agree with those that pointed out the fact that an 
informational RFC is not a legitimate standard. An 
informational RFC is intended for someone to present their 
views or information that may be of interest to the Internet 
community. In many ways, this is not much different to 
someone submitting a technical paper to be published for a 
conference (but maybe with slightly more rigor). In fact, in 
RFC 1602 section 2.4, it warns against developers trying to 
bypass the IETF process by publishing an Informational RFC 
and relying on the prestige of the RFC label to gain 
community support for their document. Although we are not 
trying to do that, the IETF will still definitely frown upon 
any abuse of the process. 

If there is sufficent concern with the confusion of having 
two standards (AIW and IETF), we might want to consider a 
fifth alternative. We can look at not pursuing an AIW closed 
pages, but just an IETF RFC. We will meet at the AIW as an 
IETF working group. This will be comparable to how the SNA 
MIB working groups are currently operating (and rather 
successfully in my opinion). This will not necessarily 
eliminate any of the issues of having to meet at both 
standard bodies, but the outcome will be only one standard. 
If we need to choose between which standard to pursue, I 
think it should be the IETF RFC.

CrossComm would like to pick the most expeditious path to get 
to a full IETF standard and think we should consider this new 
option. However, if this alternative is not acceptable then 
we would vote for choice #4 to pursue the IETF standard in 
parallel with AIW closed pages.

Regards,

Bill Kwan
CrossComm Corp.

-----

Below is the full INVITATION TO DISCUSSION text,
in case you had mislaid your copy and have not
yet responded.  Again, please respond no later than 
May 20.

INVITATION TO DISCUSSION

ISSUE:  The idea of pursuing DLSw as an IETF standard as 
well as an AIW standard has caused considerable 
controversy, both during the last AIW meeting and since 
then. 

NEW DATA:  At the IETF meeting at the end of March, we 
received some additional information that we did not 
have when we discussed this topic in February.  The main 
point is that the IETF will not accept our proposal 
based on the consensus we reached at the last meeting. 

RECOMMENDATION:  I believe it would be helpful for the 
DLSw RIG to further discuss this topic over the network, 
with the goal (if possible) of reaching a consensus 
before the next meeting in June.

CONTENTS:  This message contains a backgrounder followed 
by points for and against four possible relationships 
the DLSw RIG may choose to have with the IETF:
1)  No relationship at all.
2)  Post AIW DLSw closed pages as an informational RFC.  
3)  Pursue DLSw IETF standard after AIW DLSw closed 
        pages.
4)  Pursue DLSw IETF standard in parallel with pursuing 
        AIW closed pages.

ACTION ITEM:  Please read this message completely before 
responding.  If several people at your organization are 
involved with DLSw, please confer with them before 
responding.  

BEWARE:  Communicating in writing has inherent risks!  
We lose the tone of voice and all the non-verbal 
information.  Therefore, there is much more risk of 
misunderstanding.  Please be cautious when you write and 
be patient when you read what someone else has written.  
Acrimonious debate on this topic will hurt all those who 
are genuinely interested in a common DLSw standard.  

REMINDER:  Our group operates under the consensus model.  
We work together with a common interest.  Decisions are 
made by considering alternatives and choosing based on 
general agreement and absence of significant opposition.  

----------
BACKGROUND
----------

COMMON INTEREST:  In early 1993, a group of vendors, 
including IBM, discussed taking Informational RFC 1434 
Data Link Switching and further enhancing it to be an 
industry standard.  This is the basis of our common 
interest.

GOALS:  The early goal, to my recollection, was to 
develop, as quickly as possible, an interoperable 
specification. 

FORUM:  Both the Internet Engineering Task Force (IETF) 
and the APPN Implementers Workshop (AIW) were considered 
as possible venues for developing the DLSw standard.  
Because more of the interested vendors sent representatives 
to the AIW than to the IETF, the AIW was chosen.

FUTURE RELATIONSHIP WITH IETF:  At that early time, 
there was some discussion and a general agreement that 
we would have an eventual relationship with the IETF.  
However, some people remember this goal as "updating the 
informational RFC with another informational RFC" while 
some people remember this goal as "taking the completed 
AIW DLSw standard to the IETF to become also an IETF 
standard."  There are no records on this.

FEBRUARY AIW -- CONSENSUS REGARDING A 
RELATIONSHIP WITH IETF:  
At the Feburary AIW meeting, the DLSw Related 
Interest Group (RIG) considered this topic in great 
detail.  Several consensus items emerged from this 
meeting.  (They are included in detail in the DLSw 
meeting minutes which have been posted to the DLSw mail 
list.)  In summary, the group decided to pursue an IETF 
standard rather than an informational RFC if and only if 
certain conditions could be met.  These conditions 
included:
     	Change control: The AIW DLSw meeting and network 
would be the only forums for changing the document -- 
changes can be proposed by but not made by the DLSw 
group at the general IETF meetings.
	Intellectual property rights:  Only companies that 
have signed agreements to respect intellectual property 
rights with either the AIW or the IETF can make 
submissions for the DLSw standard.
	Leadership:  The same chair and editor were 
selected for both the AIW and IETF DLSw groups, to 
minimize problems with consistency.  The group also 
selected a vice-chair to cover any IETF meetings the 
chair cannot attend.

CURRENT RELATIONSHIP WITH IETF:  On March 29, in 
conjunction with the IETF general meeting in Seattle, 
the first DLSw Birds of a Feather (BoF) was held.  The 
IETF Area Director for this topic area, Stev Knowles, 
was present.  Stev provided information on IETF 
operations that conflicts with several of our consensus 
items:
	Change control:  The IETF can accept that the AIW 
DLSw RIG meeting can be concommitantly the IETF DLSw 
working group meeting.  However, the IETF will not allow 
the DLSw group at the IETF general meeting to be only a 
figurehead group -- they must be allowed to make submissions 
if they wish.  However, Stev Knowles noted that no final 
decisions can be made at the IETF meeting:  Final decisions
can only be made over the network - so while someone might
miss the discussions at the meeting, they do not miss the
opportunity to participate in decisions if they do not attend 
IETF.  However, this would also constrain the AIW DLSw
meeting if we were also acting as the IETF working group:  
we would need to propose ALL consensus items to the network
to get final decisions.
	Intellectual property rights:  IETF participants do 
not sign agreements.  The IETF has intellectual property 
guidelines that it encourages participants to adhere to, 
but these are not legally binding.  This leads to the 
risk that someone may make a proposal that is accepted 
as part of the standard and then later reveal that it is 
covered by a patent and demand payments. 
	Leadership:  The IETF Area Director usually accepts 
the group's proposed leaders and usually only replaces 
them for long-term non-performance.

The first two of these are important issues for several 
companies and may be show-stoppers for some.  That is, 
some  participants may be unwilling or unable (by 
company policy) to proceed with IETF under these conditions.

In summary, IETF has told us that the change control and 
intellectual property rights preferences of the AIW DLSw 
RIG are not possible.  We must therefore consider what 
relationship we want with the IETF given these 
conditions.

-----------------
END OF BACKGROUND
-----------------

--------
OPTIONS
--------

There are four possible relationships the DLSw RIG may 
choose to have with the IETF:
1)  No relationship at all.
2)  Post AIW DLSw closed pages as an informational RFC.  
3)  Pursue DLSw IETF standard serially, after AIW DLSw 
closed pages.
4)  Pursue DLSw IETF standard in parallel with pursuing 
AIW closed pages. 

(It should be noted that, for the first three options, 
nothing 
happens until closed pages while, in the fourth option, we
would start interacting with IETF immediately.  Therefore,
if we decide not to choose option 4, we could defer choosing
from among the other options until we reach closed pages.
Personally, I would prefer this debate done and over, unless
there will be information we will have at the time we reach
closed pages that we do not and cannot have now.)

Below, I present the points I have heard in favor of and 
opposed to each of these possibilities.  In your 
responses, please include additional points.

Also, as far as possible, note the relative importance 
of each of the points for you in developing your 
position.  This is important to avoid endless "Tastes 
Great!  Less Filling!" debates where two points may both 
be true but the issue is how important each is to YOU.

It is also not useful to derrogate another's comment by
reposting their comment and attempting to expose how
stupid it is.  Instead, please focus on what is important
and less important for you, your company, and your
customers, that is "We want X." rather than "They are
ignorant/obstructionist/immature for wanting Y."

(Example  1: "My customers think that an IETF standard 
is enormously safer to invest in than an informational 
RFC."  or  "My customers don't care whether it is an 
IETF standard or informational RFC -- it's just a check-
list item they need to keep management off their 
backs.") 

(Example 2:  "I just need a standard of some kind as 
soon as possible, whether from AIW or IETF I don't 
care."  or  "Timing matters, but isn't as much a concern 
for my company, since we have a successful proprietary 
solution.  So we need DLSw to have the status of an IETF 
standard before we'll build and sell it instead of 
ours.")

(Example 3:  "I'd like to trust in human decency and 
honor, but my company and users won't invest in a 
standard that has the risk of something like the 
Soderblom patent blowing up."  or  "Of course, there's 
some risk with the IETF, but DLSw is so far along that 
the risk is insignificant compared to the advantages to 
my selling an 'IETF standard.'")

In conclusion, please:

1)	State which option you prefer.

2)	State the points why this option is important to you
	or why another option is not possible/popular with you.

3)	Do NOT copy this entire posting with your message.
	It will obscure your message.

4)	Do NOT copy another person's posting with your
	message.   Instead, you can refer to another posting 
	by saying something like, "While I understand that X 
	X is an important consideration to XYZ company, 
	I believe A is more important to our customers."

NO RELATIONSHIP AT ALL
----------------------

Points in favor to NO RELATIONSHIP AT ALL:
o	Less confusion:  a single standard from a single 
body.
o	No impact on companies already attending AIW but 
not IETF.
o	Change control in a single body
o	Intellectual property rights protected by AIW 
agreement
o	Fastest delivery of a single DLSw specification
o	Less confusion in the press and with users

Points opposed to NO RELATIONSHIP AT ALL:
o	Industry respect for IETF published RFC, whether 
informational or standard.  (AIW is not well known.)
o	RFC 1434 would remain "on the books" rather than 
being updated/replaced.

INFORMATIONAL RFC
-----------------

Points in favor of INFORMATIONAL RFC:
o	Change control in a single body
o	Openly published:  Available to all interested 
parties.  
o	Intellectual property rights protected by AIW 
agreement
o	No impact on companies already attending AIW 
but not IETF - no concern about attending 6 meetings 
instead of 3 or worrying about what "they" will do at 
IETF if my company doesn't attend.
o	Faster delivery of a single DLSw specification
o	Less confusion in the press and with users

Points opposed to INFORMATIONAL RFC:
o	Additional industry respect for IETF standard over 
IETF informational RFC.
o	Our reputation might be damaged if we backed away 
from IETF standard at this point, because of all the 
press attention.

PURSUE IETF STANDARD SERIALLY, AFTER AIW 
STANDARD COMPLETE
-------------------------------------------------

Points in favor of SERIAL -- IETF AFTER AIW:
o	Group meeting at AIW maintains change control for 
at least the first release.
o	Group meeting at AIW maintains intellectual 
property rights constraints at least in the first 
release.
o	Less expensive for companies that do not usually 
send people to both AIW and IETF.
o	Because of the press coverage, the industry is
now expecting an IETF standard.
o	Would probably take less time to complete AIW 
DLSw closed pages if done before working with IETF.

Points opposed to SERIAL -- IETF AFTER AIW:
o	Some customers will balk at products based on AIW 
standard, waiting for the IETF "real thing," even if 
there are minimal changes.
o	The further in time the IETF standard is removed 
from the AIW standard, there is a greater risk of 
increased differences between them.  (Rough estimate:
9-12 months between AIW DLSw closed pages and 
IETF DLSw standard if done serially.)
o	The fewer companies that attend the IETF general 
meeting may exert greater influence than they could if 
only meeting at AIW.
o	Our users will be confused by the existence of two 
standards, even if they are almost identical.

PURSUE IETF STANDARD IN PARALLEL, WHILE 
COMPLETING AIW 
STANDARD
------------------------------------------------------

Points in favor of PARALLEL -- IETF DURING AIW:
o	Change control may be a minor concern 
because:  The AIW tends to meet about one month 
before each IETF meeting, so there would be little time in 
that month for new submissions to be made about which 
the IETF group might make a decision.
o	The chair, vice-chair, and editor can manage 
consistency between the AIW and IETF meetings.
o	Since the two standards would come out closer 
together in time, they would more likely be more similar
than if done in serial.
o	Because of the press coverage, the industry is
now expecting an IETF standard.
o	May get some valuable input from IETF community 
instead of being insulated in the SNA/APPN community.

Points opposed to PARALLEL -- IETF DURING AIW:
o	Group that meets during IETF general meeting may 
need lots of 'bringing up to speed,' wasting valuable 
time.
o	Group that meets during IETF general meeting may 
make changes that were already debated and decided at 
the AIW -- ping-pong effect.
o	The fewer companies that attend the IETF general 
meeting may exert greater influence than they could if 
only meeting at AIW.
o	Our users will be confused by the existence of two 
standards, even if they are almost identical.
o	Delivery time of a completed standard may be slowed
down due to the efforts of coordination: bringing two
groups up to speed on what each other is doing.
(Rough estimate:  Impossible to say, but could delay AIW 
DLSw closed pages

---

From: "Alan K. Bartky, Manager of Technology" <[email-masked]>
Date: Tue, 17 May 94 08:58:28 PDT

Fellow DLSw Riggers -

After reading Bill Kwan's email I would like to change Sync Research's 
opinion to the same as Crosscomm's as
5.	Alan Bartky, Sync Research     new option #5:
                                    IETF standard
                                    instead of AIW CP
                                    (or option #4)
In addition to Bill's arguments here are some of mine.

1) This group has not been working well within the confines 
of the APPN Implmentors work shop.  Changing it to IETF
working group would:
   A) Enforse Openness
   B) Enforse Deadlines (this group would have been killed
                         some time ago based on it's current
                         lack of progress)
   C) End the debate and get down to doing real work.
      (If this group were an IETF group, the same members
       would still work on the standard and attend meetings).
   D) Get something done ( a good example is how the IETF
      SNA DLC group was able to come up with a standard primarily
      of the work of Shannon Nix (formerly Netlink, now of MetaPlex)
      myself (Sync Research) and Wayne Clark(Cisco) was able to
      get the standard out in spite of the competitive nature
      of the companies (you won't find two companies more
      competitive than Sync Research and Netlink as far as
      selling SDLC to LLC conversion.

I further suggest that we can still meet at the AIW meetings
but we should downgrade the status to a "Birds of a Feather"
meeting as far as the AIW is concerned, but announce the meetings
(including to the press) as an official IETF working group
meeting (this will give the work more credibility.  This
arrangement worked very well with the SNA NAU and SNA DLC meetings.
We came to work at these meetings and got work done instead of
arguing about procedure which was already as per IETF rules.

Regards,
Alan K. Bartky
Manager of Technology
Sync Research Inc.